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(54) Based migrating user agents for personal communication services 

(57) The present Invention Is a user process that re- 
sides in network nodes to act as an agent for the mobile 
terminals in PCS environments. The user process han- 
dles all negotiatkjn and complex signaling tuncttons for 
the user, thus reducing the amount of signaling traffic 
that must travel over the valuable air interlace. To 
achieve tow call establishment times the user process 
is migrated as users move. Three embodiments of 
mechanisms for migrating the user process are dis- 
closed. The NAIVE approach enables the amount of da- 
ta size to be transferred to be optimized, leading to tow 
overhead. This approach also provides flexibility when 
migrating across heterogeneous environments. A sec- 
ond alternative, termed the TERN approach, is promis- 
ing for cases when the program is compute intensive 
and asynchronous migratton Is essentlaL The last ap- 
proach considered, Condor, provides high reliabiDty In 
the form of checkpointing, but incurs a high migratton 
delay and has high memory requirements for the net- 
work processors. 
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to as clusters 12. Within each cluster 12 are User Signaling Sen/era 14. Call Servers 16 and Conn cti n Servers 18. 
The Us r Signaling Servers 14 house multiple user processes 20 on behalf of mobfle terminals operaUng within th 
cluster. Within a cluster 12. a mobile station 24. also referred to herein as a mobile terminal, is assigned to a User 
Signaling Server 14. The user process 20 communicates with the mobile temrtinal through a base station 23 curently 
5 serving the mobile terminal, wherein the base station includes, for example, a channel server and radio port 28 to 
wirelessly communicate with the mobile. The Call Server 1 6 maintains the network state of the call and the Connectkxi 
Senders 18 are responsible for establishing the communication path over which user infomiation (voice or data) is 
transmitted. Coupled between the connection senders 18 and the base station 23 are a plurality of channel servers 25 
and switches 17, tor example, ATM switches, each of which Is also involved In establishing the communication path 
10 as would be urKierstood by one skilled in the art 

Each network contains multiple Localfon Senders 22 which are responsible for tracking the location of a mobile 
temtinal within a network. The Ljocatfan Sewers 22 are rtot associated with a cluster, but track the movement of mobile 
terminals across cluster boundaries. When a mobfle terminal is powered on it registers with a Location Server. For a 
more detailed descriptton of a cluster-based network, see related U.S. Patent Application Serial No. 08/324.427, entitled 
^ IS Method And System For Distributed Control In Wireless Cellular And Personal Communicatfon Systems, having a filing 
date of October 17, 1994, and being Incorporated herein by reference. 

Refening to FIG. 2, the registration procedure of a mobile temninal 24 is Illustrated. This registration includes a 
profile 26 provided by the mobile temr^inaL This profile 26 contains compatibifity information of the mobile terminal 24. 
whch applications are running, and any other user specific infonmatlon that Is required to create the user process. One 
20 example of User Profile data is the MOB.TERM parameter of IS-95 whfch indfcates whether the cellular user is willing 
to accept incoming calls. The Location Senrer 22 is iBsponsible for recording the current cluster of the mobile temninal 
24. and instructing a User Signaling Sender 14 to instantiate a user process on behalf of the mobile terminal. This user 
process is loaded with the user profile so that it can act on behalf of the user. 

An analogous ftow for power down reglstratkxi results In the location sender instructing the User Signaling Server 
£S to terminate the execution of the user process. 

To illustrate the functionality of the user process, the scenartos for call setup are next described. When a call is 
placed to a mobile temilnal 24. as shown in Figure 3. the network offers the call to the user process 20 representing 
the called mobile terminal. If there is any negotiation or compatibility checking that must take place between the called 
mobile terminal 24 and the calling party or the network, it occurs at this point of the call establishment through further 
30 interaction with the user process. If the user process 20 decides to accept the call, It pages its mobile terminal 24 to 
determine its exact location, for example, a specific radio-port 28 within a cluster. Thus the nwbile is tracked to the 
granularity of a cluster when it Is idle and its exact location determined at call setup time, thereby optimizing on the 
trade-off between the number of registratkxis and the amount of paging required. 

When the mobile terminal 24 wishes to place a call, as shown in Figure 4, it signals to its user process 20 and 
35 requests a call of a certain type. The user process 20 maps the call type into specific services and applications that 
are executing on the mobile terminal, and generates a call request. If there is any negotiatton that must take place 
between the mobile terminal and the called party, it is done through interaction with the user process 20. 

As has been briefly described, the present invention addresses the challenges of user process mobility rranage- 
ment by enabDng the user process to essenUally migrate along with the nx)bile user. When a mobile terminal 24 crosses 
40 cluster boundaries, it is assigned to a new User Signaling Sen/er 1 5 by the Location Server 22. According to the present 
Invention, the user process migrates from its current location to the new User Signaling Server 15. The process is 
required to migrate, and not simply be re-instantiated, because rt contains the current state of the user which must be 
preserved. These parameters include, for example, the identifiers of any calls in which the mobile temninal is currently 
active. In addition, we do not wish to repeatedly downtoad the user profile Inf onmation over the air interface. Besides 
45 creating unnecessary toad on the air hterface, this couW pose security risks for the user. 

Because a mlgratkxi between clusters Is a managed event, we do not require transparent process migration which 
has been the aim of many previous process migration efforts. In the instant case, the process itself requires that it be 
executing at a new location. Therefore, the process is aware it is migrating, can plan for the migration, and assist in 
the migration. Because a specific process is migrating and not an arbitrary one, use can be n^ade of information specific 
so to the process being migrated. For example, the user process whteh has to migrate does not have any open file de- 
scriptors and does not use any signals. Thus, the present invention mechanisnr^s need not have special purpose signal 
handling or file handling routines. 

Migratfon. in the instant case, however, is complicated by the fact that communicatfon logic is strongly coupled 
with the processing logic of the applicalion and thus, means must be provkJed for re-establishing the communication 
channels of the process after it has migrated. In "The DIANA approach to mobile computing,' T Ahmad, M. Clary. O. 
Densmore. S. Gadol. A. Keller and R. Pang. Mobidatajoumal. Vol. 1. No. 1, Nov. 1994. a new application architecture 
is proposed which decouples Ih communcation logk; from the processing k>gtc ol the appllcati n. This feature is 
particularty appealing as the migration mechanism will have to deal only with migrating th processing logic-specific 
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components, not the communteation logic. , ,^ , ^ 

The various steps involved In th migration process are illustrated in Figure 5. The User Signaling Servers (o!d 14 
and target 15) reside on two differ nt nodes in different clusters. When a mobile station 24 changes ciust rs.rtgen rates 
a REGISTRATION message to Its Location Server 22. The Location Sender 22 signals to the targ t User Signaling 

5 Sen/er 15 to migrate the process (MIGRATE), The target User Signaling Server communicates with the old User Sig- 
naling Server 1 4 which transfers all relevant information about the user process 20 to the target User Signaling Server 
1 5, for example, art data and stack pages, the state of the user, and ail user profile information. The old User Signaling 
Server 14 also maintains a stub process in place of the user process 20 to buffer any messages arriving for the user 
process while migration is undenway. The new user process 21 requests any buffered messages from the stub process 

10 residing on the old User Signaling Sender 14 and resumes its normal processing. The stub process exits after an idle 

time-out period. , , ,t «. 

Two major benefits are derived by maintaining and migrating a user process in the network: less air signaling traffic 
and tower call establishment times. The benefit of reducing the amount of signaling traffic generated over the shared 
air signaling channel results from maintaining a user process in the network. As seen in Rgures 3 and 4. few messages 
^ IS are required between the mobile lemilnal 24 and the user process 20 to establish a call. Instead, the bulk of the signaling 
^ ■ message exchange occurs between the user process and other users or senders in the network. In addition, if the user 

process does not wish to accept a call, no paging of the user terminal is required. This reduces the amount of paging 
traffic required in the networK which is a known bottleneck. The benefit of lowering call establishment times results 
from the fact that the user process is located near the mobile terminal. 

20 Another approach Is to anchor the user process In the user signaling server in which it was created during power- 

up registration. As the user moves, radte ports can be updated with the location of the anchored user process. This 
altows the new radto port of the mobile terminal to send cafl requests or other messages generated from the mobile 
to the appropriate user process. Similarly, when the nf>oblle changes clusters that are used for mobile tracking , the 
user process needs to be updated with the new paging area data altowing it to page the mobile for incoming call delivery 

3S The disadvantage is that since the ax>blle terminal may be far removed from the user signaling server where its user 
agent (UP) is located, signaling message transit times and hence call establishment times may increase. 

Figure 9 illustrates two schemes that can be used to allow a radto port 28 to communicate with any user signaling 
server 14. The first scheme Is via connectionless datagram routers 13. In this case, when mobile terminal 24 moves 
from a first radto port to a new radio port 11 , the new radio port , and possibly other radio ports within the cluster are 

$0 updated with a datagram address of the new user signaling sen/er. 

In the second scheme, connectton-oriented signalfrig links, e.g.. Asynchronous Transfer Mode virtual channel 
connection 1 5. 1 7 may be used from radto ports to user signaling servers. These signaling links can be pre-established 
or established as the users move. The advantage to the connecttonless approach is that radto port updates are simpler 
than connection setup procedures. On the other hand, connectton oriented signaling is typically faster than signaling 

3S through datagram routers. 

In any event, when analyzing migration of the user process, the associated overhead costs were analyzed to 
provide justification for possible Implementatton of the migrating user process. When considering signaling toad, we 
are most concerned about signaling messages that must travel outside of a kscalized area whtoh may congest tong 
distance, or cross-network, signaling links. 

40 TTie proposal to migrate the user process as a user changes clusters indicates that the only overhead incurred by 

migrating the user process Is the migration procedure itself. As can be seen in Figures 2-4. there is no extra signaling 
overtiead associated with registratton procedures or can control resulting from the fact that the user process migrates. 

The flow for changing clusters as shown in Rgure 5 indtoates that the MIGRATE and MIGRATE.DONE commands 
may travel on long distance slgnafing links as the location servers are located feidependently from the cluster in which 

^5 the mobile users are located. The TRANSFER comnrtand in Figure 5 requires a message exchange between two 
neighboring clusters. Therefore, the kxig distance signafing overhead associated with migrating the user process is 
limited to the MIGRATE/ MIGRATE.DONE message exchange between the user signaling servers and the tocalion 
servers. These messages total to approximately 150 bytes. 

To estimate the overhead incurred in migration, we use common assumptions for characteristics of a PCS network. 

so summarized in Table 1. Assuming that the direction of the nnovement of the temninals is uniformly 



Table 1: 



55 



Model Parameters 


Parameter 


Value 


Total number of mobile terminals 


2.87 million 


Average call origination/arrival rate 


1 .4/hourAerminal 
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Table 1: (continued) 



Mod 1 Param ter 


Parameter 


Value 


Mean Density of Terminals, p 


39Q/6q. km 


Average speed of a mobile temnlnal. v 


5.6 km/hr 


Cluster (square) edge length. L 


30.3 km 


Clusters per networl( 


128 



distributed over [0. 2«]. and using a fluid flow mobility model, tor example. •Influence o( mobHe station on the perform- 
ance of a Radio Mobile cellular network.' RThomas. H. Gilbert and G.IWIazziotto. Proo. of 3rd Nordic Sem.. paper 9.4. 
Copenhagen. Denmark. SepL 1988. the rate of mobiles crossing a cluster boundary is 

R=pvL/i[ 
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Given the values of Table 1. a single cluster experiences 5.85 boundary crossings per second. Accounting for 128 
Clusters In the network, our proposal Incurs 900 Kbps kxig distance signaling overhead network-wide. This translates 
to atout 7 Kbps at each cluster. Ttius, it is believed that the overhead Incurred m migrating the user process to enable 
fflfitAr connection setUD is a worthwhile trade-off. ... 

^^Te wven^?ons when choosing schemes for process migratfeo. First. It is required that the delay 

in miarating a process from one node to another be as small as possible. This is because the user process Is not 
pr^L JU any messages while It is migrating, and thus the time taken to migrate will manrtest .n the call seUiP delay 
Lessages happen to get queued at the old kx»tion during migration. On the other harjd, delay B^^^^^^^ 
"s^aTLior concern because the userprocess remains active while waiting for the migration to be initiated. Flexibility 
In operating environment is another concern, and thus mtes out some schemes which require a special purpose op- 

^'^*vSthmeM requirements in mind, three different embodiments are consklered for implementation of the present 
Invention, each of which offer the required flexibility. A perfomiance comparison Is then made in temis '" "^e speed o^ 
migration for different loads (which in this case is the data size of the migrant process). In each case it s assurned 
S nodes have the executable code for the user process resident, as this wiB reduce the amount of information 
that must be transferred between the source and destination nodes, and win m turn reduce the delay in migration 

STapJiSSes considered, the Condor approach, the TERN approach, and the NAIVE approach, ajf flexible .n 
temis of operating environment as they do not require access to the Internals of the operating ^f^'"- Corvdor 
can be %n entirely at the user level. The only requirement tor the TERN approach is that rt must be po^ible 
to access the kernel virtual memory of the system. The NAIVE approach requires the process to manage the migration 
itself by saving its variables and re-reading them upon migralton. ,^ o~.i,»f 

Most process migration schemes do not handle system calls relating to communication, tor example the socket 
system call, since there is the problem of hkJden state in the fom> of transit messages. In the Instant case, we only 
require that all transit messages be delivered in sequence to the process after its migration, and are not concerned as 
towhether the message intended to the user process in machine A was actually delivered to tho user Proo^^rn 
had migrated to machine B. The problem of redlrectton of messages Is similar to the one faced by the nwbile IP 
mechanisms, in which one needs to ensure that packets reach the mobile station at its new address as the mobile 
station moves. In our case, we create atemporary stub which stores any arriving messages during the migration phase, 
and fonwards them to the migrated process after It has stabilized. , ^ ^ r>~,^„, „,„„.ir,n Buctam 

The firet preferred embodiment of the user process migratkxi scheme is based on the Condor migration system. 
M Litzkowand M.Solomon. -Supporting checkpointing and process migratkxi outside the Unix Kernel.- in Usenix Winter 
conference. San Francisco. California. 1992 and M.J.LIt2kow. M.Livny and M.W.Mutka 'Condor - A Hun terof W^e 
WorkstaUons " 8th Inter- national Conterence on Distributed Computing Systems, Jan Jose. Calif.. June 1988. The 
condor system supports process migration entirely at the user level and has been Implemented on UNIX platfomis^ 
At the core of the technique is the notton of checkpointing: the process is checkpointed at one machine and resumed 
at another machine. As far as the process is concerned, the migratkx, appears to be the arrival of a signal and a setjmp 
call whfch occurs at the origmal machine, and a return from a longjmp call which occurs at the new machine 

The basic idea behind the Condor approach Is to dump the core of memory of an initial user process and then re- 
create the process at then wdestination.lnother words, ev tything in memory is transferred and then the user process 
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Is started. Referring to FIG. 7, there is shown an exemplary embodiment of a us r process 20 according to the present 
Inv ntion. As shown, the user process 20 includes two main p rtions, a core 40 and executable 42. Th c re 40 Includes 
a us r area 44. stack 46 and data storage 48. The executable 42 includes text 50, initialized data 52 and symbol and 
debugghg Information 54. As mentioned previously, the Condor approach essentially checkpoints the user process 
s from one machine to another. The new user process 21 which is checkpointed at the new machine (or user signaling 
server) includes the stack 46, symbol and debugging information 54. initialized data 52 and text 50. 

The steps involved In Implementation of the Condor approach to migrate the user process after the mobile station 
changes clusters are summarized in the flow diagram of FIG. 7A and are as foltows: 

10 1 . The User SignaOng Sewer (USS) sends a SIGTSTP signal to the user process. (110) 

2. The user process forks off a chikJ stub process that buffers the messages sent to the original user process. (1 20) 
a The parent user process now executes a se^'mp to save important registers (PC. SP. etc.) in a buffer and dumps 
a core, thus exiting. (130) 

4. The USS transfers information (data and stack pages) from the core to the target USS. (140) 
IS 5. The target USS creates the new user process using the text segment from the executable present in its node, 

and the stack and data segments received from the old USS. (140) 

6. The user process establishes its communication channels. 

7. The user process sends a READY message to the stub process and receives any outstanding messages that 
have been buffered. (150) 

20 8. The user process executes a tongjmp to continue execution from where it left off. (150) 

Note that all these steps can be achieved at the user level. The new user process created is a checkpoint file and 
can be reviewed later in the case of a rnachine or network crash. Since Condor is a general purpose mechanism, 
migration can be initiated asynchronously, that is, the process can be stopped at any point in the code and migrated, 

2S thus ensuring a qufck response to a migration call. 

A second preferred embodiment of the present inventton migration scheme is based on TERN, a transparent 
process migration mechanism descnTaed in M. Kannan, •TERN - migration mechanism and the communicatton layer. 
■ B.Tech project report Dept. of Computer Science, HT Madras, 1992 and K.G.Venkatasubramanian, 'Preprocessing 
and Run-Time System Call support for TERN/ B.Tech project report. Dept. of Computer Science. I IT Madras, 1992. 

30 As opposed to Condor, a checkpoint file is not created in this scheme. The mechanism requires information, such as 
process data and stack sizes, of an executing process. This requires access to kernel virtual memory, which is usually 
restricted to the general user. This access requirement is not a concern since the User Signaling Servers are reskJent 
in a network node, and are thus in a curtailed service environment 

Referring to FIG. 8, an exemplary implementation of the migration approach is shown. As can bo seen, a user 

55 process 20 is contained at a source node 70 and a destination node 72. The address space of each user process 
includes a text segment 74, a data segment 76 and a stack segment 78. Under TERN, the stack and data pages 76, 
78 are directly copied from the virtual address space of the user process. The bask: idea behind TERN is to start up 
a process at a destination and then copy stack and data pages onto the appropriate virtual address space. Thus a 
core dump is not required, resulting in greater efficiency as will be seen. TERN, like Condor, is a general purpose 

40 mechanism, and thus migration can be initiated asynchronously resulting in a qufck response to a migration call. 

The steps involved in migrating a user process using TERN are summarized in the flow diagram of FIG. 8A and 
are as foltows: 

1. TTie User Signaling Sender (USS) on the source node stops the user process and transfers the arguments and 
/"-^ 45 the environment of the process to the target USS. (210) 

2. The USS sets up a stub process to buffer any incoming messages. (210) 

3. The USS on the target node execte a new user process with the arguments and environment obtained from the 
source USS. (220) 

4. The USS on the source node calculates the data and stack sizes of the migrant process and transfers this 
so information to the target USS whfch ensures that the new user process expands its stack and data pages suitably 

(220) 

6. The data pages are transferred and written onto the virtual address space of the user process executing on the 
target User Signaling Server. (230) 
6. The stack pages are transferred and written. (230) 
ss 7. The user process establishes its communicatk>n channels. 

8. The user process eends a READY message to the stub process and receives any outstanding messages that 
have been buffered. (240) 

9. The register contents ar transferred and the new us r proc ss restarts from wher it was Interrupted. (250) 
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As mentioned earner, one main difference between th present requirement f r prTocess migration and other proc- 
ess migration mechanism requirem nts is that ft is known, a priori, which process is going I migrate. Thus, we need 
not have a general purpose migration mechanism and can resort to transferring only the necessary logical variabi s 
In order to increase efficiency. This type approach is presented as the third preferred embodiment for the present 
invention user process migration scheme, wherein it is termed the NAIVE approach. The steps involved are summarized 
in FIG. 10 and are as follows: 

1 . The User Signaling Sender on the target node exec*s a new user process. (310) 

2. The old user process establishes connection with the new user process. (320) 

3. The old user process transfers the data structure containing all the variables pertinent to the migration, (330) 

4. The new user process establishes its communication channels, (340) 

5. The old user process becomes a stub process and fonwards any messages to the new user process. (350) 

6. The new user process resumes Its processing. (360) 

Here, the variables crucial to the migration are placed in a suitable data structure so that modifying the user process 
code will have minimum ramifications to the migration mechanism. Examples of pertinent variables include those pa- 
rameter having to do with call connection and the state of the mobile. Relevant data pertaining to call connection may 
include, for example, type of connection, number of users, identification of the users, call type, call fonwarding and 
whether or not the mobile station will accept incoming calls. Information pertaining to the state of the mobile may 
Include, for example, terminal identities, what applications are running, e.g., Xserver running, compatibility checking, 
e.g.. video card. etc. 

Note that there are two major differences between the NAIVE approach and the TERN and Condor approaches. 
In the NAIVE approach, the migration procedures are ctosely tied to the program te>glc, therefore in the NAIVE approach 
the user process can be selective of what Information will be transferred, which significantly increases the efficiency 
of the migration procedure. For example, if a mobile station is idle, then much less information need be transferred 
than if the mobile is actively engaged. In this instance the user process makes decisions as part of the program logic 
and adjusts the volume of data that is necessary to be transferred. In the TERN and Condor approaches, on the other 
hand, the migration procedures are independent of the program togic. Also, in the NAIVE approach, the migration may 
only be initiated at certain points in the code, i.e., when all of the crucial variables have been stabilized and saved, 
whereas in the TERN and Condor approaches the migration process may begin asynchronously 

Table 2 presents a summary of the three process migration mechanisms with relation to characteristics 

Table 2: 



Process Migration Mechanism Sumnuiry 


Method 


Independent of 
program logic 


Works across 
heterogeneous 
platforms 


Asynchronous 
Initiation 


Optimizes data to be 
migrated 


NAIVE 


N 


Y 


N 


Y 


TERN 


Y 


N 


Y 


N 


CONDOR 


Y 


N 


Y 


N 



that are generally considered to be attractive in process migratfon mechanisms. The NAIVE approach has two possible 
disadvantages. First, it is not independent of program logic. It was found, however, that this did not overly complicate 
our implementation. In addition. It is this dependence that allows us to optimize the amount of data that must be trans- 
ferred during the migration. The second possible disadvantage is that the process migration may not start asynchro- 
nously. As stated previously, this does not concern our application because the user process Is active while waiting for 
migratkxi to commence; we are more concerned with the time for migration to conclude once it has begun. 

The TERM and Condor approaches have two possible disadvantages. First, the amount of data that must be 
transferred cannot be optimized. Also, nefther approach will work across heterogeneous systems. The Condor ap- 
proach has one addittonal disadvantage. It requires a large amount of memory on the User Signaling Server to ac- 
commodate the core dump during process migration. 

The per-byte cost of these schemes and the performance related issues of the migration itself can now bo exam- 
ined. As discussed earlier, one of the most Important requirements is to incur a low delay in migrating a process. Thus, 
the time taken to migrate for each of these three schemes was measured. Clearly, this time depends on the amount 
f information being transf rred between the User Signaling Servers. 
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The three schemes discussed were Implemented on UNI X platforms. A typical data point was obtain d by migrating 
a process between two machines kjcated on different ethernet kx:al area networks, and averaging th time taken to 
migrate the proc ss. The data size was varied from 1Kbyte to IMbyt , and the time to migrate for each f the three 
approaches was measured. All three schemes varied linearly with data size as expected. Howev r. the per-byte over- 
5 head differed in each of the approaches and was critfcal to the overall system performance. 

Referring to FIG. 6, it can clearly be seen that the TERN and NAiVE approaches have low per-byte cost and scale 
well with increase in data size. The TERN approach perlomns better than Condor because it is much cheaper to write 
directly onto the virtual address space of a process rather than read/Write onto the executable file. 

A key to the performance <rf the actual system is the data size of the user process and how much of it is cmcial to 
10 the migration. Current Implementation of the user process has a data size of about 72 Kbytes which must be migrated 
when using the TERN approach. This takes, on average. 750 milliseconds to migrate on the UNIX platform. In the case 
of the NAIVE approach, we were able to optimize the size of the data to be migrated to between 45 and 100 bytes 
depending on the size of the profile and whether the user was active in a call or not. This takes, on average. 150 
milliseconds to migrate. This illustrates the advantage of being able to optimize the amount of data to be transferred 
IS ' when using the NAIVE approach. 

This difference Is due to the fact that the user process consists of several protocol layers and libraries. When using 
the NAIVE approach, the user prxxess migrates only when it is in a "stable* state; that is the state of the lower layer 
data elements are inconsequential as far as migration is concemed. While this may cause a delay In the initiation of 
migration, as previously stated, this does not concem our application. 
20 The TERN approach is an attractive altematlvo if the user process evolves into a more processing intensive entity 

than in the present system. For example, in systenrw in whfch a user agent processes data being exchanged with the 
end device, it may not be possible to cleanly separate a small set of variables to be migrated. The Condor approach, 
on the other hand, is attractive only when checkpointing for reliability or other reasons is required. 

Three embodiments of possible mechanisms for migrating the user process have been presented. The NAIVE 
2S approach appears to be the most promising; in that the amount of data size to be transferred can be optimized, leading 
to k3Woverhead. This approach also provides flexibility when migrating across heterogeneous environments. A second 
alternative, termed the TERN approach, is promising for cases when the program is compute intensive and asynchro- 
nous migration is essential. The last approach conskJered, Condor, provkies high reliability in the form of checkpointing, 
but incurs a high migration delay and has high memory requirements for the network processors. 
so From the above, it should be understood that the embodiments described, in regard to the drawings, are merely 

exemplary and that a person skilled in the art may make variations and modifications to the shown embodiments without 
departing from the spirit and scope of the Invention. All such variations and modifications are Intended to be Included 
within the scope of the rivention as defined In the appended claims. 
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A method of call processing in a communicatfons network, said network including mobile stations adapted for 
wireless communteation. saW method comprising the steps of: 

registering a mobile station with said network, wherein an individual user agent is established in response to 
registration of said mobile station at a signaling server within sakJ network, and wherein sakJ user agent is 
associated with said mobile station and includes an operating profile thereof: and 

utilizing said user agent In conjunctfon with said operating profile to handle call processing functions at said 
45 Signaling sender on behalf of said nx)bile station to thereby reduce signaling kjads over an air interface of sad 

communications network. 

2. The method of Claim I. including the step of migrating said user agent from a first user signaling server in a first 
region of sakJ network to a second user signaling sender in a second region of sakl network In response to a rrxave 

so by said mobile stalfon from said first region to said second regton. 

3. The method of Claim 1 , wherein each mobile station and user signaling sender are associated with a cluster further 
including the step of migrating said user agent to a target user signaling server in a different target cluster when 
said mobile station moves to said target cluster, wherein operating parameters of sakJ user agent are presented 

ss lor use at a new locatton proximate said rrxjbiie station, thereby reducing call establishment time. 

4. The method of Claim 2. wherein operating parameters of said user agent are preserved for use at the new location 
proximate said mobile station. 
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6. The method of Claim 1, wher in said user process Is anchored at said user signaling s rver. 

8. The method of Claim 5. wherein said network includes one r nrwre radio ports to enable wireless communication 
with said mobile station, further including the step of updating said radio ports with a location of said user agent 
as said mobile station associated with said user agent moves. 

7. The method of Claim 5. wherein said network Includes one or more radio ports to enable wireless communication 
with said mobile station, wherein signaling links are established between said radio ports and a user signaling 
server in which said user agent is resWent as said mobile station nrtoves throughout said network. 

8. The method of Claim 3, wherein said network includes at least one location server for tracking the location of a 
mobile station within sakl network, said method further Including the steps of: 

generating a registration message from said mobile station to said location server upon changing clusters, 
^ IS wherein said location sen/er signals to said target user signaling sender to migrate sakf user agent of said 

nnobile station; and 

requesting and receiving user agent profile parameters at said target user signaling server from said first user 
signaling server. 

so 9. The method of Claim 2. further including the step of maintaining a stub process at said first user signaling server 
to act in place of saW user agent to buffer messages for said user agent during migration. 

10, The method of Claim 9. wherein sakl stub process exits after a predetermined idle timeout period. 

2S 11. The method of Claim 9. wherein said user agent requests buffered information from said stub process once tocated 
at said second user signaling sender, wherein normal processing by sakJ agent is subsequently resumed. 

12. The method of Claim 2, wherein said user agent is updated about a current state of said mobile station and said 
call processing functions include call acceptance and rejection and compatibility checking of data transmissions. 

13. The method of Claim 2, wherein said user agent is a user process and said step of migrating further includes the 
steps of: 

executing a new user process at said second user signaling server 
3S establishing a communications connection between a previous user process at said first user signaling server 

and said new user process; 

transferring a data structure containing migration variables from saW previous user process; 
establishing communication channels at said new user process; 
maintaining saW prevfous user process as a stub process; and 
40 forwarding messages received during migration to said new user process. 

14. The method of Claim 13, wherein said data structure Includes call and connection data and current state data 
elements of said mobile station, wherein saW call connectkxi data is selected from the group consisting of number 
of users, identification of users, call type, call forwarding and mobile call termination status, and said current state 

4S data elements of said mobile terminal Include compatibility checking procedures and applications being run at said 

mobile station. 

15. The method of Claim 2, wherein sakJ user agent Is a user process and said step of migrating further includes: 

BO stopping and saving data register contents of a first user process on said first user signaling server at a source 

node; 

transferring arguments and environment of saW first user process to said server user signaling server; 
creating a stub process to buffer incoming messages to said first user process; 

executing a new user process on a target node at said second user signaling server with said arguments and 
ss environment obtained from said user signaling sender of said source node; 

calculating data and stack sizes ol said first user process In migration at sakJ first user signaling server of saW 
sourc node; 

transferring said data stack sizes to sakl target user signaling server to thereby enabi sad new user process 
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to expand Its stack and data pages; . ... 

transf rring and writing said data pages onto said new user process executing on said target user signaling 

s rver, 

transle rring and writing said stack pages; 
establishing communication channels at said new user process; 

sending a message from said new user process to said stub process and receiving outstanding messages 
that have been buffered; and 

transferring said register contents, wherein said new user process restarts from where it was interrupted. 

16. The method of Claim 2, wherein said user agent is a user process and said step of migrating further includes the 
steps of: 

sending a stop signal from a target user signaling sen/er to said first user process; 
creating a child stub process that buffers messages sent to said first user process; 
^ IS executing a save register command from a target user process to save registers and a core dump in a buffer; 

transferring data and stack pages from said core to said target user signaling sewer; 
creating a new user process at said target user signaling sender using a text segment from an executable 
present at an associated node, and with stack and data segments received from said first user signaling server; 
establishing communication channels at said new user process; 

sending a message from said new user process to said stub process and receiving outstanding messages 
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that have been buffered; and 
executing a restore registers command at said new user process to enable continued execution from a point 
where said user process began migration. 

2S 17, A communications network including mobile stations within said network, wherein each of saW mobile stations is 
associated with a cluster within said network, said network comprising: 

at least one user signaling sewer associated with each said cluster of said network, said user signaling server 
coupled to a call sewer within said cluster, wherein saW user signaling server includes. 
30 at least one user agent, saW user agent being associated with an active individual mobile station, said user 

agent operable to handle call processing functfons on behalf of said mobile station thereby reducing air inter- 
face traffic between said mobile station and saW user signaling sewer. 

18. The network of Claim 17, wherein said user agent is further operable to migrate to another user signaling sewer 
3S in a different cluster when sakJ mobile statkxi moves to said different cluster. 

19. The network of Claim 1 8, wherein each sakJ cluster further includes: 

at least one connectfon sewer for establishing a communication path in said cluster over whteh user voice 
40 and data Information are transmitted; 

at least one call sewer for maintaining the network state of a call within said cluster; and 
at least one tocation sewer for tracking the location of a mobile station within said network, wherein sakJ mobile 
station is operable to generate a registration message to an associated location sewer upon changing clusters, 
wherein said tocation sewer signals to a target user signaling sewer to migrate said user agent associated 
^ 4S with sakj mobile statfon, and wherein said target user signaling sewer is operable to request and receive 

relevant user agent parameters from a prevtous user signaling sewer. 

20. The network of Claim 1 8, wherein a previous user signaling sewer is operable to maintain a stub process in place 
of said user agent to buffer messages for said user agent during migration, 

so 

21 The network of Claim 20. wherein saW stub process exits after a predetermined idle timeout period and wherein 
* said user agent requests buffered Informatton from said stub process once located at said target user signaling 
sewer, wherein normal processing by said agent is subsequently resumed. 

55 22. The network of Claim 18. wherein said user agent operates a user process and said user process is operable to 
migrate t^y: 

executing a new user process at a target user signaling sewer; 
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establishing a c mmunlcatlons connection between a previous user process at a first user signaling server 
and said new user process; 

transferring a data structur containing migration variables from said previous user process; 
establishing communication channels at said new user process; 
maintaining said previous user process as a stub process; and 
fonwarding messages received during migration to said new user process. 
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